System and method for integrating heterogeneous data objects

ABSTRACT

A method of integrating data objects includes: storing (i) an originating record containing a first unique identifier and a first set of data fields defining a first item supplied by a first provider, and (ii) a destination record containing a second unique identifier and a second set of data fields defining a second item supplied by a second provider; receiving an instruction to merge the originating record into the destination record, the request containing the first and second unique identifiers; in response to receiving the instruction, updating the destination record by: comparing the first set of data fields with the second set of data fields; and for each data field of the first set that matches a corresponding data field of the second set, marking the corresponding data field of the second set as a shared field; and sending the updated destination record to a client device for display.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from French Patent Application No.1905718, filed May 29, 2019, the contents of which are incorporatedherein by reference.

FIELD

The specification relates generally to computing systems, andspecifically to a system and method for integrating heterogeneous dataobjects.

BACKGROUND

Obtaining certain types of generated data may be performed via two ormore distinct generation mechanisms involving separate computingsubsystems, communication protocols and the like. However, subsets ofsuch generated data obtained via different mechanisms may neverthelessbe associated. For example, in connection with items such astravel-related products and services (e.g. flights, hotel reservationsand the like), an itinerary for a given customer may include a pluralityof flights, some of which are obtained via a first generation mechanismand others of which are obtained via a second generation mechanism.Because the generation mechanisms are independent from one another,display and applying updates to the resulting subsets of data may beaccommodated by independent interfaces.

SUMMARY

An aspect of the specification provides a method of integrating dataobjects, the method comprising: storing, at an intermediation server,(i) an originating record containing a first unique identifier and afirst set of data fields defining a first item supplied by a firstprovider, and (ii) a destination record containing a second uniqueidentifier and a second set of data fields defining a second itemsupplied by a second provider; receiving at the intermediation server,from a client device, an instruction to merge the originating recordinto the destination record, the request containing the first and secondunique identifiers; in response to receiving the instruction, updatingthe destination record by: (i) comparing the first set of data fieldswith the second set of data fields; and (ii) for each data field of thefirst set that matches a corresponding data field of the second set,marking the corresponding data field of the second set as a sharedfield; and sending the updated destination record to the client devicefor display.

Another aspect of the specification provides an intermediation server,comprising: a communications interface; a memory storing (i) anoriginating record containing a first unique identifier and a first setof data fields defining a first item supplied by a first provider, and(ii) a destination record containing a second unique identifier and asecond set of data fields defining a second item supplied by a secondprovider; and a processor connected with the communications interfaceand the memory, the processor configured to: receive, from a clientdevice via the communications interface, an instruction to merge theoriginating record into the destination record, the request containingthe first and second unique identifiers; in response to receipt of theinstruction, in order to update the destination record: (i) compare thefirst set of data fields with the second set of data fields; and (ii)for each data field of the first set that matches a corresponding datafield of the second set, mark the corresponding data field of the secondset as a shared field; and send the updated destination record to theclient device for display.

A further aspect of the specification provides a non-transitorycomputer-readable medium storing computer-readable instructionsexecutable by a processor of an intermediation server to: store, in amemory of the intermediation server, (i) an originating recordcontaining a first unique identifier and a first set of data fieldsdefining a first item supplied by a first provider, and (ii) adestination record containing a second unique identifier and a secondset of data fields defining a second item supplied by a second provider;and receive, from a client device via a communications interface of theintermediation server, an instruction to merge the originating recordinto the destination record, the request containing the first and secondunique identifiers; in response to receipt of the instruction, in orderto update the destination record: (i) compare the first set of datafields with the second set of data fields; and (ii) for each data fieldof the first set that matches a corresponding data field of the secondset, mark the corresponding data field of the second set as a sharedfield; and send the updated destination record to the client device fordisplay.

BRIEF DESCRIPTIONS OF THE DRAWINGS

Embodiments are described with reference to the following figures, inwhich:

FIG. 1 is a diagram illustrating a system for providing auxiliary dataaccess;

FIG. 2 is a diagram illustrating certain internal components of theclient subsystem and the provider subsystem of FIG. 1;

FIG. 3 is a flowchart of a method of integrating heterogeneous dataobjects;

FIG. 4 is a diagram illustrating a performance of block 305 of themethod of FIG. 3;

FIG. 5 is a diagram illustrating another aspect of the performance ofblock 305 of the method of FIG. 3;

FIG. 6 is a diagram illustrating a performance of block 330 of themethod of FIG. 3;

FIG. 7 is a diagram illustrating a performance of block 335 of themethod of FIG. 3;

FIG. 8 is a diagram illustrating a performance of block 345 of themethod of FIG. 3; and

FIG. 9 is a diagram illustrating another example implementation of themethod of FIG. 3.

DETAILED DESCRIPTION

FIG. 1 depicts a system 100 for integrating heterogeneous data objects.Within the system 100, various computing subsystems interact to generateand process data relating to any of a wide variety of activities. In theexamples discussed below, the subsystems of the system 100 interact togenerate and process data relating to the delivery of items tocustomers. The items, in the examples, below, are travel-relatedproducts and services, such as flight tickets, hotel reservations,vehicle rental reservations, and the like. A wide variety of otheractivities can be enabled by the exchange of data between the subsystemsshown of the system 100, and the specific nature of the data processedwithin the system 100 is not particularly limited.

In the illustrated example, the system 100 includes a client subsystem104, operated by a client entity that may also be referred to as aseller. The seller can be, for example, a travel agency. The clientsubsystem 104 generates requests, e.g. on behalf of customers, fortravel items. The requests specify various attributes of the travelitems, such as origin and destination locations, times and dates oftravel, and the like. Responses to requests from the client subsystem104 are generated by, or on behalf of, entities that provide the items,referred to herein as providers. Therefore, in the present example theproviders are entities such as airlines, hotel operators or the likethat deliver the items to the customer, or to other such entities foreventual delivery to the customer, following purchase of the items (suchpurchase being effected, for example, via the client subsystem 104).

Each provider entity operates a provider subsystem 108; two exampleprovider subsystems 108-1 and 108-2 are shown in FIG. 1. Each of theclient subsystem 104 and the provider subsystems 108 are implemented asat least one computing device with input and output assemblies andcommunications devices for exchanging data via a network 112. Thenetwork 112 can include any suitable combination of local-area andwide-area networks, including the Internet. Although a single clientsubsystem 104 and two provider subsystems 108 are shown in FIG. 1, thesystem 100 can include a greater or smaller number of client subsystems104 and provider subsystems 108 in other examples.

The generation of responses to requests from the client subsystem 104can take various forms. In the illustrated example, provider subsystem108-1 is assumed to generate responses to such requests locally,although as will be seen below, the requests are not transmitteddirectly from the client subsystem 104 to the provider subsystem 108-1.That is, the provider subsystem 108-1 includes an offer generationmodule (e.g. computer readable instructions and corresponding executionhardware, along with various stored data for use in generatingresponses) that enables the provider subsystem 108-1 to generateresponse data based on the attributes specified in the requestoriginated by the client subsystem 104. The response data may also bereferred to as “offer data”, and defines one or more items that match orpartially match the requested attributes.

Other provider subsystems 108, such as the provider subsystem 108-2 inthe present example, may not generate responses to requests from theclient subsystem 104. Instead, such responses may be generated by adistribution subsystem 116. The provider subsystem 108-2 may, forexample, publish data defining the items offered by the provider entitythat operates the provider subsystem 108-2 to a publication subsystem120. The publication subsystem 120 may be operated by a third party(i.e. distinct from the above-mentioned provider entities), and mayreceive published item data such as flight schedules, fares and thelike, from one or more provider subsystems 108. The distributionsubsystem 120, in turn, may retrieve data from the publication system120 for use in generating responses to requests from the clientsubsystem 104 on behalf of the provider subsystem 108-2.

In some examples, the provider subsystems 108 need not be restricted tothe use of one mechanism or the other. For example, data representingitems provided by the operator of the provider subsystem 108-1 may beobtained via either of the above mechanisms. In further examples, theprovider subsystem 108-2 may also be capable of generating responses toclient requests locally.

As will now be apparent to those skilled in the art, the generation andtransmission of requests by the client device 104, and the generation ofresponse data by or for the provider subsystems 108, can be performedaccording to either of two distinct mechanisms. The first mechanisminvolves the generation of response data locally by a provider subsystem108, and the second mechanism involves the generation of response databy a third party (e.g. the distribution subsystem 116), for example onthe basis of data previously published by the provider subsystem 108(e.g. stored by the publication system 120).

In addition, the distinct mechanisms by which response data may begenerated and provided to the client subsystem 104 can involve the useof distinct data exchange standards, communication protocols and thelike. For example, the first mechanism mentioned above, in whichresponse data is generated by the provider subsystem 108-1 itself, maybe implemented according to the New Distribution Capability (NDC)standard. The NDC standard specifies an eXtensible Markup Language (XML)based data format (e.g. specifying message syntax, API calls and thelike) for messages exchanged between client subsystems 104 and providersubsystems 108. The second mechanism, in contrast, in which responsedata is generated by the distribution subsystem 116, may be implementedas a Global Distribution System (GDS). The second mechanism, therefore,may employ message syntax, sequencing and the like as specified by theElectronic Data Interchange For Administration, Commerce and Transport(EDIFACT) standard.

In other words, data defining items may be obtained by the clientsubsystem 104 via either or both of two distinct mechanisms, each ofwhich involves interactions by distinct computing subsystems accordingto separate communication protocols, message syntax and the like. As aresult, the data defining such items may not be available to the clientsubsystem 104 in a consistent format. The client subsystem 104 maytherefore acquire data defining a first subset of items via the firstmechanism, and data defining a second subset of items via the secondmechanism. Such data may be obtained, however, on behalf of a commoncustomer; in a previous system, the client subsystem 104 may be unableto display or otherwise present the above data simultaneously.

The system 100 therefore implements additional functionality to enablethe client subsystem 104 to retrieve and display, simultaneously, a setof related data that was generated via either or both of the abovemechanisms. That is, the system 100 enables provision of a commoninterface at the client subsystem 104 for viewing data obtained viaeither or both of the mechanisms. The system 100 also enables the clientsubsystem 104 to make updates to item data from the common interface,irrespective of the mechanism by which the data was generated (andtherefore of the mechanism employed to update the data).

As noted above, the client subsystem 104 does not interact directly withthe provider subsystem 108-1. In the present example, the clientsubsystem 104 also does not interact directly with the distributionsubsystem 116. Rather, the system 100 includes an intermediation server124, and requests generated by the client subsystem 104 are transmittedvia the network 112 to the intermediation server 124. The intermediationserver 124 receives requests from the client subsystem 104, and passessuch requests to the provider subsystems 108 and/or the distributionsubsystem 116. The intermediation server 124 also receives responsesfrom the provider subsystems 108 and/or distribution subsystem 116, forreturn to the client subsystem 104.

The intermediation server 124, in the illustrated example, hosts datadefining items for the client subsystem 104, in addition to relayingdata between the client subsystem 104 and the other subsystems shown inFIG. 1. The client subsystem 104, in other words, may not storepersistent copies of data defining items locally. Instead, the clientsubsystem 104 may (e.g. following any suitable authentication process)access such data stored at the intermediation server 124. Theintermediation server 124 maintains two repositories 128 and 132, eachcontaining records of item data generated via the first and secondmechanisms, respectively. For example, the repository 128 in the presentexample contains item data obtained via the first mechanism (e.g.according to the NDC standard mentioned above), and the repository 132contains item data obtained via the second mechanism (e.g. according tothe GDS standard mentioned above).

In other examples, the intermediation server 124 can store the aboveitem data in a single repository, with each record including a flag orother indicator of the mechanism by which the data therein was acquired.In any event, as will be discussed in greater detail below, theintermediation server 124 can integrate a record from the secondrepository 132 into a record from the first repository 128 to enablepresentation of data from both records to the client subsystem 104 in acommon interface.

Before further discussion of the functionality of the various componentsof the system 100, certain internal components of the intermediationserver 124 will be described in connection with FIG. 2.

Turning to FIG. 2, the intermediation server 124 includes at least oneprocessor 200, such as a central processing unit (CPU) or the like. Theprocessor 200 is interconnected with a memory 204, implemented as asuitable non-transitory computer-readable medium (e.g. a suitablecombination of non-volatile and volatile memory subsystems including anyone or more of Random Access Memory (RAM), read only memory (ROM),Electrically Erasable Programmable Read Only Memory (EEPROM), flashmemory, magnetic computer storage, and the like). The processor 200 andthe memory 204 are generally comprised of one or more integratedcircuits (ICs).

The processor 200 is also interconnected with a communication interface208, which enables the server 124 to communicate with the othercomputing devices of the system 100 via the network 112. Thecommunication interface 208 therefore includes any necessary components(e.g. network interface controllers (NICs), radio units, and the like)to communicate via the network 112. The specific components of thecommunication interface 208 are selected based on the nature of thenetwork 112. The server 124 can also include input and output devicesconnected to the processor 200, such as keyboards, mice, displays, andthe like (not shown).

The components of the server 124 mentioned above can be deployed in asingle enclosure, or in a distributed format. In some examples,therefore, the server 124 includes a plurality of processors, eithersharing the memory 204 and communication interface 208, or each havingdistinct associated memories and communication interfaces.

The memory 204 stores the repositories 128 and 132 mentioned above, aswell as computer-readable instructions executable by the processor 200to implement various functionality. The computer-readable instructionsmay also be referred to as applications, and in the illustrated examplethe memory 204 stores a request handling application 212 and a contentintegration application 216 (also referred to herein simply as theapplications 212 and 216, respectively). In the description below, theprocessor 200, and more generally the server 124, are said to perform,or to be configured to perform, those actions. It will be understoodthat they are so configured via the execution (by the processor 200) ofthe instructions of the applications stored in memory 204.

Execution of the application 212 by the processor 200 configures theserver 124 to receive requests from the client subsystem 104 andinteract with one or more of the provider subsystems 108 anddistribution subsystem 116 to obtain response data for storage in therepositories 128 and/or 132. Execution of the application 212 alsoconfigures the server 124 to provide the above-mentioned commoninterface to the client subsystem 104, from which the client interfacecan generate requests for item data (or requests to update item data)via either of the mechanisms mentioned earlier.

Via execution of the application 212, for example, the intermediationserver 124 can implement functionality as set out in Applicant'sco-pending application no. FR 1905718 to provide the common interface.Such functionality includes the provision of data object definitions andupdate definitions that permit data to be stored in a common, aggregatedformat regardless of the source of such data (i.e. whether the data wasacquired via the first mechanism or the second mechanism). For example,the data may be stored in a common format, regardless of originatingmechanism, in the repository 128. The repository 128 may therefore bereferred to as the primary or destination repository in the discussionbelow.

However, in other instances the client subsystem 104 may initiate theacquisition of item data via the second mechanism mentioned earlier(e.g. via GDS). The intermediation server 124 may, for example, alsoinclude a further application (not shown) that enables the clientsubsystem 104 to explicitly request item data obtained via thedistribution subsystem 116, which is stored in the repository 132 and istherefore not available via the above-mentioned common interface.

The server 124 is therefore also configured, via execution of theintegration application 216, to integrate data from the repository 132into the repository 128 upon instructions from the client subsystem 104.Any data integrated by the application 216 is made available via theabove-mentioned common interface, and may therefore be viewed andupdated by the client subsystem 104 alongside data obtained via thefirst mechanism (e.g. NDC).

Turning now to FIG. 3, certain aspects of the operation of the system100 will be described in greater detail. Specifically, FIG. 3illustrates a method 300 of integrating heterogeneous data objects. Theperformance of the method 300 will be discussed in conjunction with itsperformance within the system 100, and specifically by theintermediation server 124 via execution of the integration application216.

At block 305, the server 124 receives a request, at the communicationsinterface 208, from the client subsystem 104 to merge or integraterecords containing data generated via distinct mechanisms. Inparticular, the request includes an instruction to merge a record fromthe repository 128 with a record from the repository 132. The recordfrom the repository 128 is also referred to as the destination record,as the final product of the merging operation will be stored in thedestination record. The record from the repository 132, meanwhile, isalso referred to as the originating record, as the data from theoriginating record is imported into the destination record (e.g. asindicated by the arrows connecting the application 216 to therepositories 128 and 132 in FIG. 2).

Turning briefly to FIG. 4, an example performance of block 305 is shown.The system 100 is shown in simplified form in FIG. 4, omitting all butthe client subsystem 104, the network 112 and the server 124. A request400 is transmitted from the client subsystem 104 to the server 124 viathe network 112, containing an originating record identifier “GHIJKL”and a destination record identifier “ABCDEF”. The request can have awide variety of formats beyond that shown in FIG. 4.

The records having the above identifiers are also shown in FIG. 4. Inparticular, the repository 128 contains a record 402 (the destinationrecord), having a record identifier 404 and fields or subsets of fields408 and 412. In addition, the record 402 contains a content typeindicator field 416 indicating which generation mechanism was employedto generate the data in the field or set 412. The repository 132contains a record 418 having a record identifier 420 and fields or setsof fields 424 and 428. The content of the records 402 and 418 will bediscussed in greater detail. In general, the request 400 is aninstruction to the server 124 to integrate the data in the record 418into the record 402, in order to enable viewing and updating of the datafrom both the records 402 and 418 via the above-mentioned commoninterface.

Returning to FIG. 3, having received the request at block 305, theserver 124 retrieves the relevant records (i.e. the records 402 and 414in the example illustrated in FIG. 4) and stores the originating recordidentifier 420 in the destination record 402. Thus, in the presentexample, as shown in FIG. 5, an updated destination record 402 a isgenerated from the destination record 402. The updated destinationrecord 420 a includes the previous contents of the record 402, as wellas an originating record identifier 500. The originating recordidentifier 500 enables the server 124 to continue interacting with, forexample, the distribution subsystem 116 to update data imported from therecord 418 even after the integration is complete.

At block 310, the server 124 selects a field of set of fields from therecord 418 to integrate into the record 402 a. For example, the server124 can select the “name” field 424 for integration at a firstperformance of block 310. At block 315, the server 124 determineswhether the selected field in the originating record 418 matches acorresponding field in the destination record 402 a. The correspondingfield in the destination record 402 a can be identified by way of astored field mapping maintained at the server 124. The records of therepository 128 each have the same population of fields, although thecontent of those fields varies from record to record, and certain fieldsmay be repeated different numbers of times (e.g. to represent multiplelinked items). Similarly, the records of the repository 132 each havethe same population of fields, though the structure of those fields mayvary from the fields of records in the repository 128.

The server 124 can store a preconfigured field mapping that establisheswhich fields of any given record in the repository 128 correspond towhich fields of any given record in the repository 132. In other words,the field mapping indicates which fields within the repositories 128 and132 contain corresponding types of data. For example, the field mappingin the present example can indicate that fields 408 in the repository128 (containing traveler names) map to fields 424 in the repository 132(which also contain traveler names).

Thus, at block 315, the server 124 compares the contents of the field408 as shown in FIGS. 4 and 5 with the contents of the field 424 asshown in FIGS. 4 and 5. The determination at block 315 can be adetermination of whether the fields match exactly. However, in thepresent example the server 124 is also configured to detect potentialdata collisions, in which fields that are not exactly matched should infact be merged into a single field. Therefore, at block 315 the server124 can generate a similarity metric (e.g. also referred to as a stringdistance function) from the selected fields. For example, the metric mayindicate as a percentage how similar the content of the compared fieldsis, with 100% indicating an exact match. The determination at block 315can be affirmative when the similarity metric exceeds a predefinedthreshold (e.g. 80%), and negative otherwise.

As seen from FIG. 5, in the present example the determination is assumedto be affirmative because, although the names shown in the fields 408and 424 do not match exactly, they are separated by only threecharacters (“R”, a period, and a space between the first and last names“Adam” and “Toto”). The server 124 therefore proceeds to block 320.

At block 320, the server 124 determines whether the selected fieldsmatch exactly. For example, the server 124 can determine whether theabove-mentioned metric is 100%. When the determination at block 320 isnegative, as in the example illustrated in FIGS. 4 and 5, the server 124proceeds to block 325. At block 325, the server 124 can generate awarning, such as a prompt sent to the client subsystem 104 requiringoperator action to select one of the available values (e.g. “Adam Toto”or “Adam R. Toto”) for storage in the merged record. The server 124awaits input from the client subsystem 104 making such a selection.

In the present example performance of the method 300, it is assumed thatthe client subsystem 104, in response to the prompt generated at block325, transmits a selection of the string “Adam R. Toto” for use in themerged field. Therefore, at block 330, the server 124 does not updatethe contents of the field 408, but marks the field 408 as a sharedfield, e.g. with a flag 600 as shown in FIG. 6. FIG. 6 illustrates afurther updated version of the record 402, indicated as 402 b. The flag600 indicates that the field 408 is associated with content obtained viaboth of the above-mentioned mechanisms. In some examples, the server 124can also be configured to send an instruction via the second (e.g.GDS-based) mechanism to update the name stored in the field 424 toreflect the name as stored in the field 408. When both versions of thename (i.e. as shown in the fields 408 and 424) are retained, anyinstructions sent via the second mechanism use the name as shown in thefield 424.

Following the performance of block 330, the server 124 proceeds to block340 and determines whether fields or sets of fields remain to beprocessed. When the determination is affirmative at block 340, theserver 124 returns to block 310 and selects the next field in theoriginating record 418, e.g. the field 428. In the present example, thefield mapping is assumed to indicate that “segment” fields inoriginating records of the repository 132 correspond to “item” fields indestination records of the repository 128. Therefore, at block 315 thefield 428 is compared to the field 412 as described above in connectionwith the fields 424 and 408.

As is evident from FIGS. 4-6, the values stored in the fields 428 and412 have little in common. The field 412 stores an identifier for aLufthansa flight, while the field 428 stores an identifier for a BritishAirways flight. The fields 412 and 428 may include subfields orassociated fields containing, for example, price information, origin anddestination locations, and the like. Such fields may also be comparedaccording to the field mapping. In other examples, however, only a mainvalue (such as the above-mentioned flight identifiers) may be comparedat block 315, and the subfields or associated fields can all beprocessed according to the determination based on the main field.

Following a negative determination at block 315, the server 124 proceedsto block 335. At block 335, the server 124 generates a new merged fieldin the destination record 402, and inserts therein the content of theoriginating field (i.e. the field 428 in this example). FIG. 7illustrates the result of a performance of block 335. In particular, therecord 402 b has been updated to a record 402 c, containing (in additionto previously discussed content) a field 700 that contains the flightidentifier imported from the field 428 of the record 418. In addition,as shown in FIG. 7, the server 124 can mark the merged field 700 asbeing associated with the originating record. In the illustratedexample, the marking is performed by storing a flag 704 with the field700 that indicates the distribution channel (i.e. the generationmechanism) through which the content of the field 700 was obtained.Other ways of marking the field 700 are also contemplated, however. Forexample, the identifier “GHIJKL” itself of the record 418 can be used asa flag associated with the field 700.

The creation of a field such as the field 700 at block 335 may includetransforming the data in the field 428 according to format and syntaxrequirements of the repository 128. Such transformation can be performedaccording to the data object definitions mentioned above and describedin detail in the co-pending application FR 1905718.

The above process is repeated until a negative determination resultsfrom block 340, indicating that the entirety of the originating record418 has been integrated into the destination record 402. The server 124then proceeds to block 345, at which the server 124 can transmit theupdated record 402 c to the client subsystem 104 for simultaneouslydisplay of content obtained via both generation mechanisms. In someexamples, the record 418 is discarded or marked as inactive whengeneration of the record 402 c is complete.

The system 100 therefore enables common viewing and editing of data atthe client subsystem 104 for data that was initially generated viadistinct, conventionally incompatible data generation mechanisms. Inaddition, the processes above enable continued updating of the data viasuch generation mechanisms by marking portions of the integrated datarecord with an indication of their associated generation mechanism.

Variations to the above systems and methods are contemplated. Forexample, upon receiving a request at block 305 the server 124 can applysecurity policies to the request, e.g. to determine whether the clientsubsystem 104 has access to both the records identified in the request.For example, each record in the repositories 128 and 132 can includeidentifiers of entities with access to the records, and the server 124can be configured to verify that the client subsystem 104 appears insuch identifiers in both records identified by the request.

In other implementations, data from an originating record such as therecord 418 is not merged directly into a destination record such as therecord 402. In other words, in such implementations a record such as therecord 402 c is not produced via performance of the method 300. Instead,as shown in FIG. 9, the intermediation server can maintain an additionalrepository 900. Rather than merging data from the record 418 into therecord 402 to produce an updated version of the record (e.g. the record402 c as shown in FIG. 8), the intermediation server creates anintegration record 904 in the repository 900 and stores informationtherein permitting the record 402 c to be produced on the fly fortransmission to the client subsystem 104 upon request.

More specifically, the record 904 contains a master record identifier908, corresponding to the record 402, and a merged record identifier 912corresponding to the record 418. The merged record identifier, in otherwords, takes the place of the originating record identifier 500discussed earlier. In addition, the record 904 contains one or more setsof fields indicating shared relationships between fields of the records402 and 418. In the illustrated example, therefore, the record 904contains a set of fields including an destination field identifier 916,an originating field identifier 920, and a flag 924 similar to the flag600 mentioned earlier. In some examples, the flag 924 can be omitted, asthe presence of the identifiers 916 and 920 implies that those fieldsare shared. The record 904 can also contain an identifier of acontrolling entity, such as the provider subsystem 108-1.

If a request is subsequently received for the record identifier“ABCDEF”, the intermediation server 124 retrieves the record 402 itself,as well as the record 900, and generates the record 402 c based on therecords 402, 900 and 418 for transmission to the requesting entity. Therecord 402 c need not be persistently stored, however.

In the event of a negative determination at block 320, the master recordidentifier in the record 904 dictates which “version” of conflictingdata is to be employed. The client subsystem 104 may still, however, beprompted to edit either of the records 402 and 418 to remove thecollision.

In other examples, the performance of blocks 320 to 330 can be omittedfor certain portions of a record. For example, in the present example inwhich certain fields of each record define items, the likelihood of suchfields colliding (i.e. containing data defining the same item) may below, and blocks 320 to 330 may therefore be performed only for customeridentification fields such as the fields 408 and 424. In other words,for some fields the determination at block 315 can be automaticallynegative, relieving the server 124 of the need to perform the similaritycomputations mentioned earlier. The field mapping may indicate whichfields the above shortcut applies to.

Those skilled in the art will appreciate that in some embodiments, thefunctionality of the applications 212 and 216 may be implemented usingpre-programmed hardware or firmware elements (e.g., application specificintegrated circuits (ASICs), electrically erasable programmableread-only memories (EEPROMs), etc.), or other related components.

The scope of the claims should not be limited by the embodiments setforth in the above examples, but should be given the broadestinterpretation consistent with the description as a whole.

1. A method of integrating data objects, the method comprising: storing,at an intermediation server, (i) an originating record containing afirst unique identifier and a first set of data fields defining a firstitem supplied by a first provider, and (ii) a destination recordcontaining a second unique identifier and a second set of data fieldsdefining a second item supplied by a second provider; receiving at theintermediation server, from a client device, an instruction to merge theoriginating record into the destination record, the request containingthe first and second unique identifiers; in response to receiving theinstruction, updating the destination record by: (i) comparing the firstset of data fields with the second set of data fields; and (ii) for eachdata field of the first set that matches a corresponding data field ofthe second set, marking the corresponding data field of the second setas a shared field; and sending the updated destination record to theclient device for display.
 2. The method of claim 1, wherein comparingthe first set of data fields with the second set of data fieldsincludes: retrieving a field mapping identifying, for each of the firstset of data fields, a corresponding field of the second set; andcomparing each of the first set of data fields to the correspondingfield of the second set, according to the field mapping.
 3. The methodof claim 1, further comprising storing the first unique identifier inassociation with the updated destination record.
 4. The method of claim1, further comprising: for each data field of the first set that doesnot match a corresponding data field of the second set according to thecomparison, creating a merged data field in the destination record. 5.The method of claim 4, further comprising storing, in each merged datafield, an indication that the merged data field is associated with theoriginating record.
 6. The method of claim 5, wherein the indicationthat the merged data field is associated with the originating recordincludes the first unique identifier.
 7. The method of claim 1, whereinmarking the corresponding data field of the second set as a shared fieldincludes one of: (i) storing a flag in the corresponding data field ofthe second set; and (ii) storing, in an integration record distinct fromthe originating record and the destination record, identifiers of thedata field of the first set and of the corresponding data field of thesecond set.
 8. The method of claim 1, wherein the comparing includes:determining, for each data field of the first set and the correspondingdata field of the second set, a similarity metric; and detecting a matchbetween the data field of the first set and the corresponding data fieldof the second set when the similarity metric is above a threshold. 9.The method of claim 1, wherein the originating record is a GlobalDistribution System (GDS) record, and wherein the destination recordcontains data acquired according to the New Distribution Capability(NDC) standard.
 10. An intermediation server, comprising: acommunications interface; a memory storing (i) an originating recordcontaining a first unique identifier and a first set of data fieldsdefining a first item supplied by a first provider, and (ii) adestination record containing a second unique identifier and a secondset of data fields defining a second item supplied by a second provider;and a processor connected with the communications interface and thememory, the processor configured to: receive, from a client device viathe communications interface, an instruction to merge the originatingrecord into the destination record, the request containing the first andsecond unique identifiers; in response to receipt of the instruction, inorder to update the destination record: (i) compare the first set ofdata fields with the second set of data fields; and (ii) for each datafield of the first set that matches a corresponding data field of thesecond set, mark the corresponding data field of the second set as ashared field; and send the updated destination record to the clientdevice for display.
 11. The intermediation server of claim 10, whereinthe processor is further configured, in order to compare the first setof data fields with the second set of data fields, to: retrieve a fieldmapping identifying, for each of the first set of data fields, acorresponding field of the second set; and compare each of the first setof data fields to the corresponding field of the second set, accordingto the field mapping.
 12. The intermediation server of claim 10, whereinthe processor is further configured to store, in the memory, the firstunique identifier in association with the updated destination record.13. The intermediation server of claim 10, wherein the processor isfurther configured to: for each data field of the first set that doesnot match a corresponding data field of the second set according to thecomparison, create a merged data field in the destination record. 14.The intermediation server of claim 13, wherein the processor is furtherconfigured to store, in each merged data field, an indication that themerged data field is associated with the originating record.
 15. Theintermediation server of claim 14, wherein the indication that themerged data field is associated with the originating record includes thefirst unique identifier.
 16. The intermediation server of claim 10,wherein the processor is further configured, in order to mark thecorresponding data field of the second set as a shared field, to performone of: (i) store a flag in the corresponding data field of the secondset; and (ii) store, in an integration record distinct from theoriginating record and the destination record, identifiers of the datafield of the first set and of the corresponding data field of the secondset.
 17. The intermediation server of claim 10, wherein the processor isfurther configured, in order to compare the first set of data fieldswith the second set of data fields, to: determine, for each data fieldof the first set and the corresponding data field of the second set, asimilarity metric; and detect a match between the data field of thefirst set and the corresponding data field of the second set when thesimilarity metric is above a threshold.
 18. The intermediation server ofclaim 10, wherein the originating record is a Global Distribution System(GDS) record, and wherein the destination record contains data acquiredaccording to the New Distribution Capability (NDC) standard.
 19. Anon-transitory computer-readable medium storing computer-readableinstructions executable by a processor of an intermediation server to:store, in a memory of the intermediation server, (i) an originatingrecord containing a first unique identifier and a first set of datafields defining a first item supplied by a first provider, and (ii) adestination record containing a second unique identifier and a secondset of data fields defining a second item supplied by a second provider;and receive, from a client device via a communications interface of theintermediation server, an instruction to merge the originating recordinto the destination record, the request containing the first and secondunique identifiers; in response to receipt of the instruction, in orderto update the destination record: (i) compare the first set of datafields with the second set of data fields; and (ii) for each data fieldof the first set that matches a corresponding data field of the secondset, mark the corresponding data field of the second set as a sharedfield; and send the updated destination record to the client device fordisplay.